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FLBOBLE WLAN ACCESS POINT ARCHITECTURE CAPABLE OF ACCOMMODATING 
DIFFERENT USER DEVICE CAPABILITIES WITH STRONG SECURITY 

IEEE 802.1 1 based wireless LANs (WLANs) are becoming extremely popular these 

tZS^SZ^JF^ ^ WLANS iS S6CUrity ' ***** for ^ANs deployed 
at public hot spots. How to provide secure access solutions that only allow authenticated 

accesses and protect authenticated user sessions from eavesdropping is the key problem 

to be solved ,n offering any public hot spot WLAN services. Compounding Z problem 

is the fact that the users of the service may have wireless devices with differed ? 

S^^ d i C ° n ? gUrati0nS - * P 3 *™ 18 *' s °nie of these devices may be equipped 
with IEEE 802. Ix client programs, while others may onlv have simple WPP k*«h 
encryption mechanism. In this invention, we propose a wireless LAN access poinT 
solution that can accommodate such different user device capabilities and select the best 
ava, ^^able authentication mechanism for each wireless device accordingly. None oflhe 
existing WLAN access point or public hot spot access solution offers such a feature We 

ntTo-' TT ^ POint * at iDte ^ ated this feature me soTutior 

has been tested and proven to work well. 

As far as we know, none of the existing wireless LAN access points and public access 
solutions is capable of accommodating different types of wireless device capabiHties 

Offering secure access at public WLAN hot spots has become increasingly important 
tiiese days/There are several different ways in achieving such a goal in fhe existing 
solutions. The most promising solution uses IEEE 802. lx, which is becoming the 
standard ™ providing secure WLAN authentication. One problem with such a solution is 

o^aZT ?f 8 ° 2 - 1X CUent S ° ftWare inSta,,ati ° n *» d co «fi^ation. Since it was 
originally intended as an enterprise solution, many existing IEEE 802.1 x clients are not 
convenient to use in public hot spots. In addition to these issues, the IEEE 802 lx 
protocol does not have a sophisticated mechanism for interacting with the user The 

Sf^f Ca 5r°" y T d Simple ° ne ' Way messa g es to the client via EAP notification. 
This may be sufficient for an enterprise setting but in a hot spot, the access point might 

Z^^V° r CeP i a " ^ ^ IiCCnSe bef ° re aUowin S access - ° r * toe ^ess pofnt 
might want to inform the user about the charges for the service. Our solution provides 
access point the capability to interact with the users via the web browser interfacT 
Another solution for secure access is based on the use of web browsers. It enables many 
user interactions and ,s very intuitive to the users. With certain enhancements suchT* 
those described in our earlier patent application [1], it can offer strong security. Thus we 
envision both approaches will co-exist and it is highly likely that a variety of wireless 

I n uhl S. ™ Z^* 0 * E ? E l 021 * ca P abilities > wi » ^ on the market for a long time. 
A public WLAN hot spot, therefore, should accommodate such different client 
capabilities, based on which the WLAN should select different authentication 
mechanisms. As far as we know, none of the existing public hot spot WLAN solutions 
has such a feature. In this disclosure, we describe our solution that can achieve this 
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An embodiment architecture 

The prototype that we have developed consists of the following key modules that are 
relevant to the current invention: 

• 802. IX Engine 

This module implements the IEEE 802. IX protocol with the enhancements that we 
propose. It is responsible for client detection and providing the client capability 
information to other modules of the system. In addition it also implements RADIUS 
client functionality to convert EAP messages to RADIUS messages. 

• Packet Filter module 

As the name suggests, the packet filter module is responsible for filtering packets based 
on the criteria set by other modules. 

• HTTP server 
Client detection 

When a wireless client associates with the WLAN, the WLAN must first determine the 
client capability, i.e. whether it has an IEEE 802. 1 x client software. In order to 
understand how this can be done, we first look at the IEEE 802.1x protocol sequence in 
ngure 1 . As we can see from the figure, when the WLAN initiates the protocol sequence 
with a Request-Identity EAP packet, the IEEE 802. lx client always responds with a 
Response-Identity EAP packet. A wireless device without the IEEE 802. lx client will not 
be able to understand the Request-Identity EAP packet and thus won* send the right 
response. Based on this, the WLAN AP can detect wireless client capability and use the 
corresponding authentication mechanism for each client 
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EAP Response-Identity 



EAP Success/Failure 



RADIUS Authentication Request 



RADIUS Authentication Response 



Figure I. 802.IX Authentication Sequence 
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Authentication state management 

Note that the client capability detection is done by the IEEE 802. lx engine at the AP. 
Such information must be conveyed to the higher layer to control client accesses. For 
example, 

• for non IEEE 802. 1 x clients, IP packet filtering must be configured properly to 
redirect user HTTP requests to the local server, and when the HTTP requests are 
redirected, the HTTP server should present the users with information 
specifically related to the browser based authentication (see [1]) 

for IEEE 802. lx clients, besides allowing normal IEEE 802. lx protocol exchanges to go 
through, the AP also sets up proper IP packet filtering and state information for the 
HTTP server to control user accesses during and after IEEE 802. lx based authentication 
process. 

As we can see from the above discussion, the WLAN system must maintain proper state 
information for the proper functioning of the system. Such state information will be 
supplied by the 802. lx engine and used by, among other things, the packet filtering 
function and the HTTP server. As an example embodiment, we shall describe how this is 
done in our prototype WLAN AP. The 802. lx engine may create one of the following 
states: 

• lx_progress: Indicates that the client is an IEEE 802. 1 x client and the 802. 1 x 
authentication process is ongoing. 

• lx_failure: Indicates that the 802. lx authentication process failed for some 
reason 

• 1 x_success: Indicates that the 802. 1 x authentication process succeeded 

• non_lx: Indicates that the client is a non-IEEE 802.1x client. Because for such a 
client, all access controls are done at the higher layers, no further classification of 
state is necessary. 
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1 ^failure 



EAP Failure 



Redirect client 



Web Access Request 



1x_failure State Based Page 




RADIUS Access Request 



RADIUS Access Reject 



Web Request Redirect 



Authentication Server 



Figure 2. 802. lx authentication failure 



As an example of how such information can be used, consider the case when an 802. lx 
client fails authentication for some reason (figure 2). When the client tries to access the 
web, the packet filtering function in the WLAN would redirect user requests to a local 
web page according to this state. The page may ask the user to check the 802. lx 
configuration, or try the web browser based authentication. 
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